Database management becomes a task of ever increasing complexity as the volume of data contained in a database grows. Demands for precision data mining ability for that data also grows. Data is useless if it cannot be located and accessed in an efficient manner
Efficiently displaying, modeling, reviewing and editing of relationships in a database between different data types has been exceedingly difficult. An entity type is data representing one particular set of data or entity (e.g., a data table in a database). Entity Types can be thought of as common nouns and entities can be thought of as proper nouns. Examples: a computer, aircraft, navy ship, automobile, tank, engine, an employee, a song, a mathematical theorem. A “relationship” is data indicating how one entity data type is related to another. Such data about the relationship data is metadata. Relationship metadata is the collection of relationship specifications that have been defined for the system.
An “entity” is a specific physical data table structure grouping of a set of data elements that have a repeatable set of properties. Non-limiting examples of “entities” for a maintenance database may include component functions, component failure modes, failure mode symptoms and repairs for failure modes.
A relationship captures how entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Examples: An aircraft has engine relationship that links aircraft to its engine. An “aircraft” may have a failure modes relationship that links the aircraft and all of its related failure modes. A failure mode may have symptom relationships that link a failure mode to symptoms of a failure mode. A recursive relationship is one in which the same entity participates on both sides of the relationship. Additional information concerning entities, relationships and attributes are discussed further in co-owned, co-pending patent application Ser. No. 13/794,155, which is incorporated herein by reference in its entirety.
Conventional approaches for displaying and managing entities of various data types, and managing the relationships between them, are cumbersome and redundant. Moreover, because a relationship can carry additional significant data values in and of themselves (i.e., relationship attributes), any relationships between two entities necessarily become a three dimensional relationship (including the relationship) that is difficult to perceive and edit. When a relationship between any two entities (e.g., Entities A and B) is desired to be reported or the relationship between them is to be modified, only a single two-dimensional rendering of the relationship can be generated. If a relationship between two other entities (Entities B and D) is also desired only a second two dimensional rendering (i.e., a cross tab) can be generated. The same situation presents itself when relationships between any two entities include multiple parameters or values (i.e., attributes). In that case multiple different renderings must be generated for each combination and/or permutation of entities and their attributes. Further, to the extent that new relationships or relationship attributes need to be added to the knowledgebase, each data table the knowledge base must be updated and amended directly, which is also cumbersome and time consuming
It should be noted that while commercial spreadsheet applications such as Excel® sold by Microsoft Inc. of Redmond, Wash. create crosstab displays such as a two variable data table or a pivot table, the information contained in the cells of the table is static. The static data is not data driven or equation driven. Directly changing the content of a data table or a pivot table is ineffective because there is no mechanism to reverse edit a relationship table in the knowledge base from the cross tab display. Reverse editing as used herein is the ability to edit the underlying data tables directly by changing, adding or deleting symbols in a cell of a cross tab display. Conventionally, a user may create a special relationship table but there is still no means for reverse editing it from the cross tab display. The relationship attributes in the cross tab display must be edited elsewhere in order to get an updated cross tab display.
Hence, there is a need for systems and methods to allow database system users to perceive and edit multidimensional relationships amongst data entities. Additionally, there is a need for a reversely editable graphical user interface (GUI) rendered on a display screen of a computing device that allows users to intuitively edit various data structures within a data base by manipulating data cells in the reversely editable GUI.